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Abstract — Replay  attacks  on  security  protocols  have  been  dis¬ 
cussed  for  quite  some  time  in  the  literature.  However,  the  efforts  to 
address  these  attacks  have  been  largely  incomplete,  lacking  gener¬ 
ality  and  many  times  in  fact,  proven  unsuccessful.  In  this  paper  we 
address  these  issues  and  prove  the  efficacy  of  a  simple  and  general 
scheme  in  defending  a  protocol  against  these  attacks.  We  believe 
that  our  work  will  be  particularly  useful  in  security  critical  appli¬ 
cations  and  to  protocol  analyzers  that  are  unable  to  detect  some  or 
all  of  the  attacks  in  this  class. 

Index  Terms — security  protocols,  replay  attacks,  adapted  strand 
spaces,  run  identifiers,  component  numbers. 

I.  Introduction 

EPLAY  attacks  have  been  discussed  for  quite  some  time 
in  the  literature  (eg.  [1],  [2],  [3],  [4]).  We  generalize  the 
definition  of  a  replay  attack  as:  an  attack  on  a  security  proto¬ 
col  using  replay  of  messages  from  a  different  context  into  the 
intended  (or  original  and  expected)  context,  thereby  fooling  the 
honest  participant(s)  into  thinking  they  have  successfully  com¬ 
pleted  the  protocol  run. 

Syverson  in  [2]  presents  an  exhaustive  taxonomy  of  replay 
attacks  classifying  them  at  the  highest  level  as  run-external  and 
run-internal  attacks,  basing  on  the  origin  of  messages.  Each  of 
these  can  be  further  classified  into  interleavings,  classic  replays, 
reflections,  deflections  and  straight  replays  basing  on  message 
destination. 

Traditional  methods  to  include  nonces  have  proven  to  be  of 
little  value  against  replay  attacks  (eg.  [5],  [6]).  Attempts  to 
use  time-stamps  in  messages  were  beset  with  problems  such 
as  dealing  with  the  asynchronous  world  [1],  Gong  and  Syver¬ 
son  present  fail-stop  protocols  under  a  restrictive  class  of  pro¬ 
tocol  design  rules,  that  avoid  these  attacks  under  certain  condi¬ 
tions  [3],  Some  other  attempts  have  been  exclusively  directed 
towards  countering  reflections  [7],  These  mechanisms  work 
by  including  the  identity  of  sender,  recipient  or  both  in  mes¬ 
sages.  Suggestions  of  binding  cryptographic  keys  to  their  in¬ 
tended  use,  specialized  use  of  shared  keys  to  identify  sender 
and  receiver  have  been  cited  in  numerous  places  including  [8], 
[9],  [10],  [4]  but  are  effective  only  in  limited  contexts  eg.  re¬ 
flections  and  deflections  but  not  straight  replays.  Syverson  dis¬ 
cusses  these  counter-measures  exhaustively  in  [2], 
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Strategies  presented  to  counter  reflection  attacks  using  for¬ 
mat  asymmetry  fail  if  the  format  asymmetry  is  itself  attackable. 
Although  format  asymmetry  (type-flaws)  was  proven  to  with¬ 
stand  type-flaw  attacks  by  Heather  et.  al  [11],  the  suggested 
scheme  of  component  numbering  as  a  corollary  does  not  con¬ 
sider  attacks  using  interleaving  of  different  protocols 1 .  Guttman 
et.  al  prove  “protocol  independence”  through  disjoint  encryp¬ 
tion  and  suggest  a  protocol  numbering  scheme  to  achieve  dis¬ 
joint  encryption.  However,  there  is  not  yet  an  international  stan¬ 
dard  on  protocol  numbering  (to  identify  each  protocol).  An¬ 
other  suggestion  in  the  same  paper  is  to  use  a  different  key¬ 
ing  material  for  each  application — an  indeed  strong  assumption 
since  it  is  unlikely  to  be  followed  by  all  users  due  to  the  high 
cost  of  certified  keys.  This  was  also  discussed  in  [8], 

Thus,  one  can  observe  some  visible  characteristics  in  all 
these  solutions — They  are  either  unsuccessful,  or  too  specific. 
Some  of  them  are  too  expensive  to  implement  and  some  oth¬ 
ers  are  interdependent  (eg.  as  discussed  above  where  solutions 
using  format  asymmetry  depend  on  type  tagging  or  component 
numbering  and  these  in  turn  depend  on  using  disjoint  encryp¬ 
tion).  Hence,  an  interesting  question  to  ask  would  be,  “can 
these  interdependencies  be  taken  advantage  of  to  launch  new 
kinds  of  attacks?”. 

Most  of  the  automated  analyzers  also  fail  to  detect  at  least 
one  attack  in  this  class.  Although,  NRL  protocol  analyzer  was 
observed  to  have  been  able  to  detect  all  types  of  replays  given 
by  Syverson,  it  was  still  observed  to  be  difficult  to  analyze  for 
specific  attacks  in  this  class  [12],  However,  prevention  is  an¬ 
other  matter. 

Carlsen  presents  a  list  of  type  information  that  can  be  at¬ 
tached  to  messages  and  elements  [13].  These  include  protocol 
identifier,  protocol  run  identifier,  primitive  types  of  data  items, 
transmission  step  identifier  and  message  subcomponent  identi¬ 
fier.  Aura  [4]  studies  these  techniques  and  comes  up  with  some 
strategies  against  replay  attacks  that  are  neither  necessary  nor 
sufficient  but  enhance  the  robustness  of  a  protocol.  A  recent 
trend  in  the  literature  has  been  to  prove  protocol  security  against 
specific  attacks  by  suggesting  tagging  messages  with  one  of  the 
type  information  suggested  by  Carlsen  (eg.  [14],  [11]). 

1  Intuitively,  different  protocols  can  have  different  messages  with  the  same 
component  number,  still  making  it  vulnerable  to  type-flaws.  The  original  sug¬ 
gestion  to  tag  with  primitive  types  of  data  items,  however,  would  be  effective  in 
the  presence  of  interleaving  of  different  protocols  but  is  expensive  to  implement 
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In  the  same  spirit,  we  prove  that  all  replay  attacks  can  be  pre¬ 
vented  by  tagging  each  encrypted  component  with  a  session- 
id  (another  name  for  Carlsen’s  protocol  run  identifier)  and  a 
component  number  (renaming  Carlsen’s  message  subcompo¬ 
nent  identifier).  However,  unlike  previous  attempts,  our  sug¬ 
gestion  is  a  general  solution  and  prevents  all  types  of  replay 
attacks  in  Syverson’s  taxonomy.  Although  it  is  not  an  entirely 
new  solution,  it  solves  the  problem  of  replays  using  a  combined 
solution  that  is  devoid  of  any  possible  vulnerabilities  due  to  in¬ 
terdependencies. 

Introducing  component  numbers  inside  encryptions  is  intu¬ 
itive,  but  the  generation  and  use  of  session-ids  requires  some 
explanation.  Some  have  discussed  tagging  messages  with  all 
the  information  that  is  in  possession  of  a  principal  and  relevant 
to  the  protocol  [15].  This  is  also  called  the  principle  of  full  in¬ 
formation.  Aura  [4]  hints  at  a  trivial  way  of  including  a  hash 
of  all  previous  messages  in  a  protocol  run,  almost  as  a  substi¬ 
tute  to  the  principle  of  full  information  and  the  run  identifier. 
This  is  prudent  to  some  extent.  In  fact,  as  Aura  points  out,  it 
is  enough  to  include  only  a  hash  of  the  redundant  data  that  is 
already  known  to  the  receiver.  This  doesn’t  adversely  affect  the 
performance  for  obvious  reasons.  However,  careful  observation 
of  this  suggestion  reveals  a  possible  vulnerability — two  proto¬ 
col  runs  can  overlap  in  the  executed  information  at  a  typical 
stage  of  the  runs ! 

Therefore,  we  suggest  a  different  approach  to  generate 
session-ids  to  identify  runs.  For  the  purpose  of  this  discus¬ 
sion,  it  suffices  to  know  that  such  identifiers  can  be  gener¬ 
ated  to  be  used  in  an  effective  way  and  will  possess  a  neces¬ 
sary  property — remaining  unique  to  every  protocol  run.  Briefly, 
all  participants  need  to  choose  a  random  number,  and  combine 
those  into  a  single  long  string  of  random  bits.  This  value  should 
be  hashed  together  with  the  identities  of  all  principals,  reducing 
the  chance  of  an  accidental  match  in  session-ids  to  a  great  ex¬ 
tent.  Two  features  are  necessary  to  generate  such  an  identifier 
1.  Every  principal  should  possess  the  same  hash  function.  2. 
A  change  in  one  of  the  random  numbers/principals’  identities 
should  make  the  resulting  value  differ  from  it’s  original  value. 

Observe  that  the  generated  session-id  is  different  in  proper¬ 
ties  from  other  similarly  used  identifiers.  For  example,  the  run 
identifier  used  in  Otway-Rees  protocol  [16]  is  generated  by  only 
one  participant  and  hence  was  shown  to  be  prone  to  replay  at¬ 
tacks  [17].  It  is  also  similar  to  “cookies”  coined  in  Photuris  [18] 
which  are  an  add-on  that  can  be  used  to  make  a  protocol  more 
resistant  to  DOS  attacks.  A  cookie  is  a  unique  nonce  computed 
from  the  names  of  the  sending  and  receiving  parties  and  local 
secret  information  that  only  the  sender  possesses.  Cookies  pro¬ 
vide  initially  weak  authentication  to  users  while  they  aid  in  sub¬ 
sequent  establishment  of  strong  authentication.  Session-ids  are 
similar  to  cookies  in  the  kind  of  initial  assumptions  and  their 
ultimate  use,  except,  unlike  cookies  where  only  the  sender  is 
aware  of  the  value,  a  session-id  is  publicly  known. 

However,  the  publicly  known  identifier  needs  to  be  unique 
for  every  protocol  run.  Intuitively,  a  dishonest  principal  might 
use  a  different  value  from  the  pre-agreed  upon  value.  (In  fact, 
this  will  be  definitely  true  if  he  replays  components  from  previ¬ 
ously  completed  runs  and  not  from  interleaved  runs).  However, 
the  proof  we  are  going  to  present  will  establish  that  even  such 


behavior  does  not  succeed  in  breaking  a  protocol  in  this  scheme. 
Further,  hashing  with  participants’  identities  (cited  as  useful 
in  numerous  places  including  [4],  [7],  [10])  prevents  other  at¬ 
tempts  to  spoof  user  identities  and  launch  man-in-middle  type 
attacks. 

The  proof  we  are  going  to  present  in  this  paper  follows  a  sim¬ 
ple  concept  to  establish  the  desired  results,  following  a  proof 
structure  laid  out  in  [11]: 

If  a  protocol  is  secure  in  the  absence  of  replays,  it  is  also  se¬ 
cure  under  our  tagging  scheme  in  the  presence  of  replay  attacks 

OR 

Whenever  there  is  an  attack  on  a  protocol  using  the  tagging 
scheme,  there  should  also  be  an  attack  on  the  protocol  in  the 
absence  of  replays 

The  utility  of  the  result  of  this  paper  is  manifold.  Firstly, 
it  reduces  the  task  of  protocol  analyzers  that  fail  to  detect  any 
subset  of  replay  attacks  and  increases  the  trust  in  the  remaining 
analysis.  Secondly,  it  gives  more  leverage  to  a  protocol  designer 
with  the  implicit  protection  that  it  provides  against  many  known 
threats.  Lastly,  it  is  relatively  inexpensive  to  implement  such  a 
scheme  especially  compared  to  those  for  example,  that  require 
unique  keys  for  each  application. 

The  rest  of  the  paper  is  organized  as  follows:  In  the  next  sec¬ 
tion  (2),  we  will  introduce  our  model  of  a  protocol.  In  section  3, 
we  will  show  that  any  given  bundle  can  be  transformed  into  an 
equivalent  but  well-tagged  bundle.  In  section  4,  we  will  prove 
our  main  result.  We  illustrate  our  concepts  on  the  Otway-Rees 
protocol  as  an  example  in  section  5  and  end  with  a  conclusion. 

II.  The  Protocol  Model 
A.  Tags,  Facts  and  Subfacts 

Tags  and  Facts2  are  defined  in  the  model  as: 

Tag  ::=  JOIN  SID  CNO 
Fact  ::=  UF  \  EF  |  JOIN  Fact  Fact 
UF  ::=  JOIN  Atom  UF 
EF  ::=  ENCR  TF 
TF  ::=  JOIN  Tag  Fact 

where  UF,  EF,  TF  represent  unencrypted,  encrypted  and 
tagged  fact  respectively. 

uf,  ef  denote  the  set  of  unencrypted  and  encrypted  facts 
respectively.  Atom  is  the  set  of  atomic  values  (eg. 
Alice,  Bob,  Na,  PubKey(A)  etc.)  assumed  to  be  contained 
in  a  protocol. 

Often  we  need  a  projection  function  on  tagged  facts  to  obtain 
the  tag  or  fact  components,  defined  as: 

(t,f)i=t,  (t,  /)2  =  /. 

We  will  denote  the  set  of  session-ids  as  sid  and  the  set  of 
component  numbers  as  cno.  A  typical  tag  in  a  run  a  shall  be 
written  as,  ( sida,cno ).  The  first  part  is  the  session-id  of  a 
and  the  second  part  is  the  component  number  for  one  of  the 

“Facts,  components  or  messages  will  be  used  interchangeably  but  message 
will  be  used  to  mean  the  entire  collection  of  facts  sent  in  a  single  protocol  step. 


encrypted  facts  of  a.  JOIN  and  ENCR  represent  concatenating 
two  data  items  and  encrypting  a  data  item  respectively.  When 
two  data  items  a,  b  are  to  be  concatenated,  we  will  write,  a  .  b 
or  (a,  b).  When  a  data  item  a  is  to  be  encrypted  with  a  key  k, 
we  will  write,  { a }  /. .  Also,  subfact  relation  [I  on  facts  is  defined 
as  follows: 

Definition  1:  The  subfact  relation  is  the  smallest  relation  on 
facts  such  that: 

1)  /  c  /; 

2)  fn{tf}k>  if  /c(i/')2; 

3)  /  c  C/1,/2)  iff  c  /1  v/  c  f2. 

Also,  f  rtf  if  (f,  /)  c  tf. 

B.  Adapting  Strand  Space  Model  with  Tagged  Facts 

In  this  section,  we  define  a  new  adapted  strand  space  model 
from  the  original  strand  space  model  [19]  to  suit  tagged  facts. 

Definition  2:  A  strand  is  a  sequence  of  communications  by 
either  an  agent  (honest  or  dishonest)  in  a  protocol  run.  It  is 
represented  as  a  sequence  of  facts  (±/l,  ±/2, . . . ,  ±/n).  A 
‘+’  indicates  transmission  of  a  fact  and  ’  indicates  reception 
of  a  fact.  Every  node  in  the  set  of  nodes  A f  transmits  or  receives 
a  fact  (±/)  and  belongs  to  a  unique  strand. 

1)  Let  ni, Hi- 1-1  be  consecutive  nodes  on  the  same  strand. 
Then,  there  exists  an  edge  nt  =>  n,+  i  in  the  strand. 

2)  If  n,  =  +/  and  rij  =  —  /  are  nodes  belonging  to  different 
strands,  then  there  exists  an  edge  Hi  — >  n, . 

3)  AT  together  with  both  the  sets  of  edges  n,;  =>  n,+1  and 
Hi  — >  Uj  is  a  directed  graph,  (JV,  (— >  U  =>)). 

A  bundle  represents  a  particular  event  history  of  the  com¬ 
munication.  It  is  an  acyclic,  finite  subgraph  of  (A f,  (— >  U  =>)). 
Formally,  if  -4Cc-^,  and  (—*c  U  =>c)  is  a  finite  set 

of  edges,  then  C  =  (—*c  U  =>c)  is  a  bundle  if: 

1)  whenever  n2  £  A fc  receives  a  fact,  there  exists  a  unique 
ni  such  that  n\  —>c  n'2‘, 

2)  Whenever  n2  £  A fc  with  m  =$■  n2,  n±  =>c  n2  £  C\ 

3)  C  is  acyclic. 

A  node  n  is  an  entry  point  to  a  set  of  facts  F  if  no  node  previous 
to  n  has  a  fact  +/  with  /  £  F.  A  fact  originates  on  n  if  n  is 
an  entry  point  to  {/'  |  /  C  /'}.  Similarly,  a  tagged  fact  tf 
originates  on  n  if  n  is  an  entry  point  to  {tf  \  tf  C  tf'}.  A 
fact  or  a  tagged  fact  is  uniquely  originating  in  a  bundle  if  it 
originates  on  a  unique  node  of  the  bundle. 

1 )  Honest  Strands:  We  use  the  concept  of  strand  tem¬ 
plates  [11]  to  define  roles  in  a  protocol.  These  templates  make 
use  of  a  set  of  variables,  Var  defined  as  below: 

Var  ::=  UV  \  EV  |  JOIN  Var  Var 
UV  ::=  AtomVar  |  JOIN  AtomVar  UV 
EV  ::=  ENCR  TaggedVariable 

TaggedVariable  ::=  JOIN  TagV ar  V dr 


where,  UV  -  Unencrypted  Variable,  EV  -  Encrypted  Variable. 
TagV  ar  -  Tag  Variable. 


Var  consists  of  unencrypted  (uv),  encrypted  (ev)  and  func¬ 
tion  variables  (fv)3)  with  fv  C  uv.  We  define  an  instantiation 
function  ins  to  instantiate  elements  in  Var,  to  correspond  to 
elements  in  Fact. 

Let, 

inst  :  Tag  Var  — »  Tag,  and  inst,  :  AtomVar  —  Atom 

so  that,  V  tu  £  Tag  Var  A  v  £  AtomVar, 

inst(fu)  =  t  and  insv(u)  =  /  for  some  t.  £  Tag  A  f  £  Atom. 

Combining  inst  and  insv,  we  define  ins  as: 

ins  :  Var  — >  Fact 

so  that  Vi>  £  Var,  ins(u)  =  /,  for  some  /  £  Fact. 

Also,  ins  can  be  defined  on  all  possible  variables  as: 

■  ,  x  f{(inst(tu,),insv(w,))}msv(fc')  v  =  {(tv1  ,v’)}k> 
[(ins(ui),  ins(u2))  v=(vi,v2). 

As  an  example,  let  temp  represent  the  role  ‘6’  in  the  Woo 
and  Lam  protocol  III  [15]: 

temp  =  (-(a),  +(nb), -(x),  +({t2,  a,  b ,  x}shbs), 

-  ({t3,a,b,nb }shbs)) 

fix’  represents  that  ‘6’  is  not  expected  to  decrypt  this  variable, 
according  to  the  protocol). 

A  typical  execution  by  Bob  ( B )  in  a  run  6  with  Alice  (A), 
would  look  like  (assuming  that  Bob  is  honest): 

ins  (temp)  =  (-(A),  +  (NB),  -  (A), 

+  ({(SIDP,  CN02),A ,  B,  X}shBS), 

-  ({( SIDp ,  CN03),A,  B,  NB}shBS)) 

where, 

ins(a)  =  A,  ins (b)  =  B ,  ins(s)  =  S,  ins(?ib)  =  NB, 
ins)®)  =  {(SIDp,CNOi),A,  B,  NB}shBS(=  X). 

It  is  important  here  to  note  that,  the  function  ins  can  be  de¬ 
fined  to  map  to  a  new  set  of  values  each  time.  So  that,  this 
captures  the  aspect  of  different  protocol  runs  containing  differ¬ 
ent  values.  It  is  also  interesting  to  see  for  which  mapping  of  the 
ins  function,  we  will  be  able  to  obtain  an  attack  on  a  protocol. 

2)  Correct-tagging:  An  encrypted  fact  is  said  to  be  well- 
tagged  if  the  tag  component  of  the  fact  has  the  correct  session- 
id  and  component  number  in  it,  i.e.  the  encrypted  fact  is  being 
generated  and  sent  in  the  expected  context.  We  capture  this 
using  the  formalizations  that  we  present  below. 

Let  S*  represent  the  strand  spaces  of  all  possible  protocol 
runs,  where  the  single  protocol  run  q£S*  and, 

CNo  :  S*  x  ef  — >  cno  such  that, 

3 Function  variables  are  of  the  form,  APPLY  Fn  UV  where  F„  is  any  func¬ 
tion.  eg.  Hash,  PK  etc. 


v/i,  h  e  ef  •  f  f  h  =►  CNo(a,  A)  f  CNo(a,  /2) 

Also  let,  Sid  :  S*  — >  sid  such  that  Vet  €  S*  •  Sld(a)  G  sid 
Vai,a2  G  S*  •  ai  f  ct2  Sld(cti)  f  Sld(a2) 

These  properties  ensure  unique  tags  for  every  subcomponent 
of  any  protocol  and  any  run  of  a  protocol. 

Using  Sid  and  CI\lo,  an  ideal  tag  environment,  lo  can  be  for¬ 
mally  defined: 

lo  :  E*  x  ef  — >  Tag  such  that. 

Vet  G  E*,  V/  G  ef  •  co(a,  /)  =  (Sld(a),  CNo(a,  /)) 

So  that,  for  each  protocol  run  a,  Sld(a)  is  the  session-id  for 
a.  (when  the  context  is  understood,  we  will  simply  write  oo(f)). 

Definition  3:  Let  /  =  be  a  fact  in  a  protocol  run  a; 

then  well-tagged (/)  can  be  inductively  defined  on  all  possible 
facts  as  follows: 

•  if  (tf)  2  G  uf  then4  well-tagged(/)  (t/')i  =  u(f); 

•  if  (tf)  2  G  ef  then,  well-tagged(f)  iff 

well-tagged((f/'j2)  A  (tf)  i  =  u>(f); 

•  well-tagged  (/i,/2)  (well-tagged(/i)  A 

well-tagged(/2)) 

Note  that,  well-tagged  is  a  partial  function.  Therefore,  it  is 
undefined  for  facts  that  are  not  encrypted. 

Assumption  1:  There  exists  an  ideal  tag  environment,  lo,  for 
each  set  of  strands  representing  a  protocol  run,  that  is  obtained 
by  instantiating  a  set  of  strand  templates  such  that  all  the  facts 
in  the  protocol  run  are  well-tagged  with  respect  to  lo. 

Assumption  2:  If  the  fact  /  originates  on  a  regular  strand, 
then  well-tagged(/). 

In  other  words,  we  assume  that  an  honest  agent  always  tags 
an  encrypted  fact  with  a  correct  tag  (as  defined  above).  On  the 
other  hand,  we  allow  a  penetrator  to  tag  a  message  with  any 
arbitrary  tag.  If  a  fact  is  ill-tagged,  this  would  mean  that  either 
the  penetrator  has  “replayed”  it  from  another  context  or  he  did 
not  chose  to  tag  with  the  correct  component  number  and/or  the 
pre-agreed  upon  session-id. 

3 )  Penetrator  Strands:  We  make  two  changes  in  the  pene¬ 
trator  strands  in  this  model — firstly,  we  assume  that  a  penetra¬ 
tor  possesses  a  set  of  encrypted  facts,  Ep  that  he  would  have 
somehow  obtained  (e.g.,  by  eavesdropping  over  a  network,  or 
obtained  in  a  previous  run  in  which  he  was  a  legitimate  user), 
in  addition  to  a  set  of  keys  Kp  and  texts,  Tp.  Secondly,  we  in¬ 
clude  a  replaying  (R)  strand  to  capture  the  action  of  a  penetrator 
replaying  an  encrypted  component. 

Definition  4:  A  penetrator  strand  is  one  of  the  following: 


4By  definition,  subscript  “2”  is  a  projection  that  returns  the  fact  component 
of  a  tagged  fact  (section  II- A). 


M  Text  message  (+/)  with  /  G  Tp. 

F  flushing  (-/). 

T  Tee  <-/,+/,+/>. 

C  Concatenation  (— f,  —  /2,  +/1/2). 

S  Separation  ( -  f  f2 ,  +  fix ,  +/2 }  ■ 

K  Key  (+k)  with  k  G  Kp. 

E  Encryption  {-k,  -/,  +{(t,  /)}*),  k  G  KP. 

D  Decryption  -{(t,  /)}*,  +/),  k  G  KP. 

R  Replaying  (+/),/  G  EP. 

Note  that  we  consider  not  only  replaying  of  encrypted  com¬ 
ponents,  but  also  replaying  of  unencrypted  components.  In  fact, 
we  allow  the  penetrator  to  replay  a  message  of  any  type  into  a 
message  of  a  different  (expected)  type.  For  example,  an  Atom 
in  place  of  an  Atom,  an  Atom .  in  place  of  an  encrypted  com¬ 
ponent,  an  encrypted  component  in  place  of  an  encrypted  com¬ 
ponent  and  so  on.  For  example,  sending  a  message,  /1./2  with 
fi  G  uf  and  Jy  G  ef  in  place  of  f  G  uf  can  be  constructed  as 
a  sequence  of  M  and  R  strands. 

However,  this  does  not  restrict  the  generality  of  the  scheme. 
As  we  will  show  in  the  proof,  the  scheme  also  prevents  all 
such  type  flaw  attacks  too,  due  to  component  numbering.  The 
session-id  helps  in  preventing  all  type-flaw  attacks  that  occur 
not  only  in  the  same  run  or  a  different  run  of  the  same  protocol, 
but  also  those  that  occur  from  a  different  run  using  a  different 
protocol. 

Lemma  1:  Every  ill-tagged  fact  originates  on  an  E  or  an  R 
strand. 

Proof.  According  to  assumption  1,  ill-tagged  facts  do  not 
originate  on  honest  strands.  The  only  possible  strands  for  the 
origin  of  a  fact  are,  M,  K,  E  and  R  strands.  In  the  case  of  M 
and  K  strands,  there  is  no  tagging.  In  the  case  of  n  E  strand,  it 
may  or  may  not  be  well-tagged  (we  do  not  restrict  the  penetrator 
to  put  correct  tags  inside  encryptions).  That  leaves  us  with  R 
strands.  Since  these  involve  replaying  old  messages,  they  would 
necessarily  be  ill-tagged. 

III.  Transforming  Bundles 

A.  Oven’iew 

In  this  section,  we  focus  on  transforming  bundles  to  “well- 
tagged  bundles”.  We  will  show  that,  given  a  bundle  C,  we  can 
change  all  the  tags  in  C  so  that  the  resulting  bundle  has  facts,  all 
of  which  are  well-tagged.  Since  we  assume  that  an  honest  agent 
checks  all  accessible  tags  in  a  message  that  he  receives,  we  do 
not  change  the  tags  inside  those  messages.  On  the  other  hand, 
receiving  an  ill-tagged  fact  that  cannot  be  decrypted  should  not 
change  the  behavior  of  an  honest  agent  when  it  is  changed  to 
well-tagged.  This  is  the  sole  concept  around  which  our  trans¬ 
formation  revolves. 

B.  The  Transformation  Function,  if 

The  definition  below  states  the  required  properties  of  if: 

Definition  5:  Given  a  bundle  C,  executed  in  an  ideal  tag  en¬ 
vironment  lo,  we  define  ft  :  Fact  — >  Fact  to  be  a  transforma¬ 
tion  function  that  transforms  C  as  a  well-tagged  bundle  if: 

1)  if  preserves  unencrypted  facts:  if  if>(f)  =  /  if  /  G  uf. 

2)  if  returns  well-tagged  terms:  well-tagged(t/>(/)). 


3)  ip  is  the  identify  function  over  well-tagged  terms: 
if  well-tagged  (/)  then  ip(f)  =  /. 

4)  ip  distributes  through  encryptions: 

=  {(w(/),^(/))}fc 

5)  ip  distributes  through  concatenations: 

V>(/l,/2)  =  (V-(/l),^(/2)) 

6)  When  ip  is  applied  to  an  ill-tagged  fact  /  of  C,  it 
produces  a  fact  that  has  an  essentially  new  tag.  i.e.  a  fact 
that  has  a  tag  not  in  common  with  ip(f')  for  any  other 
fact  /'  of  C: 

V/,/"  G  ef ,  ^well-tagged(/)  A/'c  ip(f)  A  (f)2  ± 

(f"h  =*■ 

(/'WW  )i 

This  establishes  an  injectivity  property  for  ip  over  facts  of 

C. 

The  following  lemma  proves  that  such  a  ip  can  always  be 
found: 

Lemma  2:  For  any  given  bundle  C  in  an  ideal  tag  environ¬ 
ment  u>,  it  is  possible  to  define  some  transformation  function  ip 
for  C. 

Proof:  The  method  we  give  below  gives  a  recipe  for  con¬ 
structing  a  transformation  function  ip  defined  in  definition  5. 
Let  there  be  a  fact  /.  We  shall  define  how  the  transformation 
would  be  done  on  all  possible  smallest  sub  facts  of  /  before 
defining  it  on  /  itself. 

1)  If  /  G  uf,  lift  the  transformation  function  on  /  for  con¬ 
dition  1:  ip(f)  =  f . 

2)  If  /  =  {(£',  f)}k'  G  ef  and  well-tagged(f),  then,  define 

i  f')}k’  =  for  condition  3. 

3)  If  /  =  G  ef,  /'  G  uf  and  -.well-tagged(/), 

then,  define  ip{(t',  /')}*/  =  {(f",/,)}fc'  so  that  t"  = 
uj(f')  for  condition  3. 

4)  If  /  =  G  ef,  /'  G  ef  and  -.well-tagged(/), 

then,  define  ip{(t' ,  f')}k>  =  {(/",  ip(f))}k’  where  t"  = 
u>(f)  for  condition  4. 

5)  If  /=  (/l,  /2),  then  define  ip(f)  =  (ip(fl),ip(f2))(iov 

condition  5). 

6)  Since  t o  generates  unique  tags,  condition  6  is  satisfied. 


C.  Regular  Strands 

If  5  is  a  regular  strand  (=  ins  (temp)  for  some  strand 
template  temp),  then  ip(S)  is  also  a  regular  strand.  Con¬ 
sider,  S'  =  \ns'(temp)  and  ins'(u)  =  'i/(ins(u))  so  that, 
ins'(u)  =  ins(r;),  \/v  G  uv.  The  following  lemma  proves  that 
S'  is  a  regular  strand  obtained  by  transforming  all  the  facts  in 
S  to  be  well-tagged,  using  ip. 

Lemma  3:  Let  temp,  ip,  ins,  ins'  be  as  above;  Then, 
ip(\ns(temp))  =  ins'(temp). 

Proof:  Let  v  be  a  variable  in  temp.  We  will  do  a  case 
analysis  of  all  the  possible  forms  that  v  can  take  in  temp : 


•  Case  v  is  an  encrypted  fact;  say,  v  =  {(tv',  v')}kvr,  then: 

tp(  ins(»)  =  ip({(\nst(tv'),\nsv(v'))}mSv{kv/)) 

=  {(instO'),  insv(u/))}insv(fe«') 

(from  condition  3  of  definition  5  and  since 
well-tagged(ins(r;))  from  assumption  2) 

=  {(msftv'),  insv(r/))}insv(fc«') 

(by  assumption  2,  and  since 
well-tagged(ins'(u)),  ins((fu')  =  inst(ft/)) 

=  ins'(u) 

(from  definition  of  ins  and  ins(,(r/)  =  insv(u/), 
ins(,(fci/)  =  insv(fcu')) 

•  Case  v  is  a  pair;  say,  v  =  (vi,v2)',  then, 

t/’(ins(u))  =  '0(ins(ui),  ins(u2))  (by  definition  of  ins) 

=  (^>(ins(ui)),  t/(ins(u2)))  (cond.  5  of  def.  3) 

=  (ins'(ui),  ins'^))  (from  above  results) 

=  ins'^i,  u2) 

=  ins'(u) 


D.  Penetrator  Strands 

In  this  section  we  will  show  how  we  transform  penetrator 
strands  in  C  to  equivalent  penetrator  strands  in  the  well-tagged 
bundle  (say  C'),  without  any  additional  penetrator  knowledge. 
We  consider  each  type  of  penetrator  strand  defined  in  defini¬ 
tion  4  and  define  a  corresponding  strand  in  C .  In  most  cases, 
we  will  preserve  the  strand  structure,  but  will  retain  the  same 
set  of  facts  in  every  case. 

•  M  Text  message:  Let  S  =  (+x)  with  x  G  Tp.  Define 
S'  =  (+ip(x)),  which  is  an  M  strand  because  ip(x)  =  x 
when  x  G  uf  from  condition  1  of  definition  5. 

•  F  Flushing:  Let  S  =  (— /).  Define  S'  =  (-ip(f)),  which 
is  an  F  strand. 

•  T  Tee:  Let  S  =  (—/,+/,+/).  Define  S'  = 

(— ip(f),  +ip(f),  +ip(f)),  which  is  a  T  strand. 

•  C  Concatenation:  Let  S'  =  (—f\,~f2,+fif2).  Define 
S'  =  (-tp(fi),-tp(f2),+ip(fi,  f2))  which  is  a  valid  con¬ 
catenation  strand,  because  ip(fi,  f2)  =  (tp(fi),tp(f2))  by 
condition  5  of  definition  5. 

•  S  Separation:  Let  S  =  (—fifi,+f\,+f2)-  Define  S'  = 
{-tp(fi,f2),+ip(fi),+ip(f2))  which  is  a  valid  separation 
strand,  again  by  condition  5  of  definition  5. 

•  K  Key:  Let  S  =  ( +k )  with  k  G  Kp.  Define  S'  = 
(+ip(k)),  which  is  a  K  strand  since  ip(k )  =  k,  Vfc  G  uf 
from  condition  1  of  definition  5. 

.  E  Encryption:  Let  S  =  (— k,  —  f,  +{(i,  /)}fc),  k  G  KP. 
Define  S'  =  (-ip(k),-ip(f),+ip({(t,  f)}k))  which 

is  a  valid  encryption  strand  because,  ip({(t,  f)}k)  — 
{io(f),ip(f)}k  by  condition  4  of  definition  5. 

•  D  Decryption:  Let  S  =  (-k~\-{(t,f)}k,+f),k  G 
KP.  Define  S'  =  {-ip(k  1),  -ip({(t,  f)}k),+ip(f)). 


which  is  a  valid  decryption  strand  because, 
=  {(^(/),V’(/))}fc  by  condition  4  of 

definition  5. 

«  R  Replaying:  Let  S  =  (+/),/  €  Ep.  Define  S'  = 
(+'*/'(/))  which  is  a  valid  replaying  strand  because,  ip(f) 
is  merely  well-tagged  without  any  additional  change  in  the 
message. 

One  special  case  here  concerns  when  the  penetrator 
receives  a  well-tagged  fact  and  sends  another  fact  in 
it’s  place,  either  by  replaying  or  by  “retagging”:  i.e. 
a  combination  of  (a)  F  and  R  strands:  (— /,  +//) 

with  f  G  Ep  or  (b)  D  and  E  strands:  (— /,+/'} 
((-{(ii)/i)}fci,-fci,+/i,+{(f2,/2)}fc2,-/c2,+/2)),  with 
h ,k2  G  Kp,  /  =  {(fi,  /i)}fel  and  f  =  {(t2,  /2)}fc2. 

E.  Preserving  Unique  Origination  in  Bundles 

Using  ip,  for  every  edge  +n  — »  —  n  in  C ,  we  have  created 
a  similar  edge  +ip(ri)  — >  —ip(n)  transforming  C  into  a  well- 
tagged  bundle.  We  have  applied  ip  only  on  the  tag  component 
of  a  tagged  fact.  We  did  not  introduce  new  facts  any  where  in 
the  bundle.  We  have  changed  the  strand  structure  in  the  special 
case  where  a  penetrator  receives  a  fact  and  replays  a  fact  or 
retags  a  fact,  which  is  dealt  with  as  explained  above. 

Lemma  4:  Let  C  and  C  be  defined  as  above.  If  /o  is  a  fact, 
uniquely  originating  in  C,  then,  /o  also  originates  uniquely  in 
C'. 

Proof:  ip  is  effectively  applied  only  on  ill-tagged  facts. 
From  Lemma  1,  they  originate  only  on  E  and  R  strands.  By 
definition,  ip  does  not  change  the  fact  component.  Also,  by  the 
injectivity  property  of  ip,  there  is  no  duplication  of  tags.  Hence, 
unique  origination  is  preserved  in  C' .  ■ 

IV.  Proof 

A.  Overview 

In  this  section  we  will  prove  our  main  result,  whenever  there 
is  an  attack  on  a  protocol  using  our  tagging  scheme,  there  is 
also  an  attack  on  the  protocol  in  the  absence  of  replays.  To  be 
precise,  we  need  to  prove  that. 

If  there  is  an  attack  on  a  protocol  under  the  tagging  scheme, 
there  is  also  an  attack  on  the  protocol  when  adopting  the  tag¬ 
ging  scheme  with  all  tagged  messages  correctly  tagged. 

In  other  words,  an  attack  on  a  protocol  using  the  tagging 
scheme  does  not  revolve  around  replays.  We  will  consider  an 
attack  to  mean  a  failure  of  authentication  at  the  end  of  a  proto¬ 
col  run.  Any  other  properties  can  be  similarly  considered  and 
proven,  e.g.,  non-repudiation,  anonymity,  fairness.  For  defin¬ 
ing  security  properties  and  their  violations,  we  will  follow  the 
definitions  and  terminology  given  by  Heather  et.  al  [11].. 

B.  Authentication 

Theorem  1:  Let  C  he  a  bundle  and  C  be  a  well-tagged  bun¬ 
dle  obtained  by  transforming  C.  i.e.  ip(C)  =  C' .  If  there  is  a 
failure  of  authentication  in  C,  there  is  also  a  failure  of  authen¬ 
tication  in  C". 

Proof: 


Suppose  there  is  a  failure  of  authentication  in  C  as  below  [11, 
definition  2] : 

1)  There  is  a  strand  si  =  insl(fempl)  with  C-height  at 
least  hi.  (an  honest  strand  in  C  with  C  at  a  minimal 
height  hi). 

2)  Vfc  G  Keys  .  insl(fc)  ^  Kp.  (no  secret  keys  are  com¬ 
promised). 

3)  There  is  no  strand  s2  =  ins2(temp2)  with  C-height  at 
least  h.2  such  that  \/x  G  X  •  insl(rc)  =  ins2(a;).  (there 
is  no  matching  strand  for  si  in  C,  agreeing  on  some  data 
set  X).  (This  says  that  since  there  is  no  matching  honest 
participant  to  match  the  accepted  authentication  in  si,  the 
authentication  is  bogus.) 

We  show  that  there  is  a  corresponding  attack  in  C .  Let, 
insl'(v)  =  -i/>(insl(u)).  Then: 

1)  There  is  a  strand  si'  =  insl'(templ)  =  ip{\nsl(templ)) 
with  C'-height  at  least  hi,  corresponding  to  si,  from  the 
way  we  have  constructed  the  honest  strands  of  C' . 

2)  Vfc  G  Keys  •  insl'(/c)  ^  Kp,  because  insl'(fc)  = 
insl(fc)  for  such  k. 

3)  There  is  no  strand  s2'  =  \ns2' (temp2)  with  C'-height  at 
least  h2  such  that  Va;  G  X  .  insl'(;r)  =  ins2'(;r). 

Suppose  there  were  such  an  s2';  then,  by  the  way  we  have 
constructed  the  honest  strands  in  C',  s2'  would  correspond  to 
some  strand  s2"  =  \ns2"  (temp2)  with  C'-height  at  least  h2 
such  that: 

\/v  G  Var  .  ins2'(u)  =  ^(ins2"(u)) 

But  then,  we  would  have  for  every  x  G  X: 

V’(insl(a:))  =  insl'(a’) 

=  i  ns2'  (at) 

=  ^>(ins2"(x)) 

However,  contradicting  part  3  of  the  definition,  we  would 
have  insl(a;)  =  ins2"(:r),  because  of  the  injectivity  property  of 
ip  (condition  6  of  definition  5). 


C.  Example 

We  illustrate  our  concepts  with  the  Otway-Rees  protocol. 
Thayer  et.  al  establish  a  number  of  properties  of  this  proto¬ 
col  in  [20,  section  7.2],  This  protocol  can  be  represented  in  our 
scheme  in  the  form  of  the  following  templates: 

init  =  (+(M,  A,  B{ti,M,  Na,  A,  B}Kas), 

-  ( M{t3,Na,KAB}KAS )) 

resp  =  (-(M,  A,  B{h,M,  Na,  A ,  B}Kas), 

+  (M,  A,  B{ti,M,  Na,  A,  BjKAS{t2,  Nb,  M,  A,  B}Kbs ), 

-  (M{t3,  Na,  KAB}KAS{ti,  Nb,  Kab}Kbs), 

+  (M,  {h,Na,  Kab}Kas)) 

serv  =  (-(M,  A,  B{ti,  M,  Na,  A,  B}KAS{t2,  M,  Nb,  A, 
+(^{^3>  Na,  KAB}KAS{t4,  Nb,  Kab}i<bs)) 

Thayer  et.  al  also  extend  these  results  when  this  protocol  is 
executed  in  a  “mixed”  environment  [21],  when: 


1)  Ticket(Lo)  =  set  of  all  terms  of  the  form  {NK'}k  is 
unserved  in  S.  i.e.  secondary  strands  (strands  belonging 
to  other  runs)  do  not  have  entry  points  to  this  set. 

2)  Request(Lo)  =  set  of  all  terms  of  the  form  {N M AB} k 
is  strongly  unserved  i.e.  no  term  of  this  set  ever  originates 
on  a  secondary  strand. 

3)  L0nKP^; 

In  particular,  they  establish  the  following  ‘initiator’s  guaran¬ 
tee’  under  the  above  assumptions: 

If  s  £  Ylinit  is  an  initiator  strand  in  a  bundle,  then  there  al¬ 
ways  exist  primary  strands  sresp  £  Tiresp  and  sserv  £  Tiaerv 
which  agree  on  the  initiator,  responder,  and  M  values,  i.e.  au¬ 
thentication  is  guaranteed  w.r.t.  [11,  definition  2]:  there  is  no 
failure  of  authentication  if  tempi  =  init,  temp2  =  resp,  X  = 
{A,  B ,  M},  hi  =  hi  =  4  and  Keys  =  {/v^s}. 

We  can  again  use  our  main  result  in  section  IV  to  show  that 
this  protocol  achieves  this  guarantee  even  when  all  the  three 
conditions  are  dropped  and  the  tagging  scheme  adopted  (with 
the  appropriate  ins  defined  on  init  and  resp).  In  addition,  com¬ 
ponent  numbering  assures  us  that  the  protocol  remains  invulner¬ 
able  to  the  type-flaw  attack  shown  in  [17]  which  succeeds  due 
to  replay  of  encrypted  components  inside  the  same  run. 

V.  Conclusion 

Many  times  protocols  are  successfully  attacked  when  an  hon¬ 
est  agent  incorrectly  accepts  messages,  “believing”  that  they 
possess  some  properties  (eg.  freshness).  Whether  a  technique 
prevents  certain  attacks  depends  upon  preventing  the  honest 
user  from  accepting  messages  that  do  not  have  their  claimed 
properties  and  on  the  inability  of  the  penetrator  to  create  ‘valid’ 
messages  having  those  properties.  In  this  paper  we  have  intro¬ 
duced  one  such  scheme  to  prevent  replay  attack  and  proven  that 
it  stops  replay  attacks.  In  particular,  we  have  taken  an  arbitrary 
bundle,  used  a  transformation  on  it  to  change  it  to  a  well  tagged 
bundle,  where  no  term  represents  replays.  This  was  possible  be¬ 
cause,  if  an  honest  agent  is  willing  to  accept  an  ill-tagged  fact,  it 
should  accept  any  value  in  it’s  place.  Attacks  were  then  shown 
to  be  existing  on  both  or  on  none,  indirectly  proving  that  the 
attacks  are  not  based  on  replays,  but  on  some  other  mechanism. 
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